FIG. 1 illustrates a network element for establishing single bindings according to the prior art. FIG. 1 illustrates the network element 111 (e.g., the SMS™ Platform and/or SmartEdge® Platform sold by Redback Networks, Inc. of San Jose, Calif.) having a number of ports 104-104I and 108A-108I, a layer 2 demultiplexer unit 105, a remote database server 110, a number of virtual circuit units 102A-I, a set of one or more control modules 106, and a number of contexts 107A-I. Each of the contexts 107A-I provides the functionality of a router (e.g., a layer 3 router supporting at least the Internet protocol (IP)), and thus operate as virtual routers in the network element 111. Depending upon the configuration of the network element 111, each context 107A-I can be associated with a different provider or service (e.g., video service, on-line gaming service, an Internet service provider, a content provider, etc.) through output ports 108-108I to allow for separation of traffic of different services (e.g., for accounting and other purposes). However, a different or additional allocation of contexts may also be possible (e.g., different services of a given provider may be allocated to different contexts, certain providers may share a single context, etc.). A given context may include a number of subnets that comprise a number of addresses (e.g., Internet Protocol (IP) addresses) that are to be dynamically assigned to subscriber/clients.
By way of example, a number of computing devices 101A-I are coupled to the port 104A by an access network 103. In contrast, the ports 108A-I are used for communication by the contexts to the services. It should be understood that any number of ways can provide communication between the ports 108A-I and external services according to well known techniques (e.g., a connection over the Internet, such as a virtual private network (VPN) using, for example, GRE tunneling, L2TP tunneling, ATM/FR logical channels, 802, 1Q VLANS, direct IP connectivity, MPLS L2/L3 VPNS etc).
Different communication sessions between the computing devices 101A-I may travel through different ones of the contexts 107A-I. Thus, each of the contexts 107A-I have one or more interfaces to provide communication out of port(s) 108, and also have one or more interfaces to which the computing devices may be bound depending upon the service that has been selected by a subscriber. While in FIG. 1, each context is associated with one of ports 108A-I, other configurations are possible (e.g., a given context may be associated with multiple ports 108A-I; different contexts may be associated with the same set or overlapping sets of one or more ports 108A-I; etc.). The control modules 106 handle various communications, protocols, network connections, bindings, etc.
The remote database server 110 stores data related to authentication, authorization and accounting (AAA) for subscribers. While in one embodiment, the remote database server 110 is a Remote Access Dial In User Server (RADIUS) server (e.g., with a sequel (SQL) database, such as MySQL), alternative embodiments may use additional RADIUS servers and/or instead or additionally use other types of servers. It should be understood that any number of ways can be used for providing communication between the remote database server 110 and the network element 111 according to well known techniques (e.g., a connection over the Internet, such as a VPN carrying a software program/script (e.g., perl based scripting) for RADIUS attribute/element modification and Pre-emptive Hypertext Processor (PHP) based web interfacing to link the necessary databases of both).
The access network 103 represents any number of different access networks using any number of different types of encapsulations, including channelized media (e.g., DSL) and non-channelized media (common for cable modem services). For example, the point-to-point protocol (PPP) is commonly used for DSL services. PPP requires a client to be installed on the computing devices that allow a subscriber to enter a username and a password, which in turn may be used to select a context. As another example, when Dynamic Host Configuration Protocol (DHCP) is used (e.g., for cable modem services), a username typically is not provided by the computing device; but in such situations the Media Access Control (MAC) address of the hardware in the computing device (or customer premise equipment modem) is provided. The use of DHCP and clientless internet protocol (IP) selection (CLIPS) on the network element allows capture of a MAC address automatically on any DHCP state change occurring in the connection between a computing device and the network element. This MAC address may be used to distinguish subscribers so that contexts may be selected for them based on data in the remote access server. As yet another example, a protocol agnostic technique for context selection called domain-less service selection may be used to select contexts (see application Ser. No. 20/464,233; filed Jun. 17, 2003).
Additionally, FIG. 1 illustrates exemplary operations for computing devices 101A and 101I. FIG. 1 illustrates a given computing device 101A and another given computing device 101I communicatively coupled to the network element 111 through access network 103 and port 104A. The layer 2 demultiplexer unit 105 is coupled to port 104A and represents well known hardware, software, and/or firmware for separating a multiplexed signal carrying packets from one or more subscribers. In FIG. 1, layer 2 demultiplexer unit 105 communicates: 1) the data packets of computing device 101A with virtual circuit unit 102A; and 2) the data packets of computing device 101I with virtual circuit unit 102I. A virtual circuit unit is software, hardware, and/or firmware established for a particular subscriber session (When a subscriber session is complete, the associated virtual circuit unit is typically torn down). In FIG. 1, virtual circuit unit 102A and virtual circuit unit 102I are populated through AAA 108A and AAA 108I respectively. Furthermore, virtual circuit unit 102A and virtual circuit unit 102I respectively include packet analyzers 112A and 112I (well known software, hardware and/or firmware to access header information from packets) to provide quality of service and/or access control list operations. The virtual circuit unit 102A and virtual circuit unit 102I respectively include single bindings 115A and 115I. The virtual circuit unit 102A is bound to the context 107A by the single binding 115A. The virtual circuit 102I is bound to the context 107I by the single binding 115I. Virtual circuit units may include additional functions (e.g., quality of service, access control lists, etc.).
As illustrated in FIG. 1, the network element 111 is restricted to single bindings, meaning a particular subscriber is bound to only one context at a time through a network device 111. Since, FIG. 1 requires subscribers to be bound to only one context, a particular subscriber on computing device 101A is unable to switch between services accessed through different contexts without reauthorization (e.g., requiring the subscriber to logout and login again). When a subscriber on computing device 101A attempts reauthorization in order to access a service through a different context, the subscriber must be unbound from their current context and be bound with the other context.
FIG. 2 is a time based data flow diagram illustrating an exemplary use of reauthorization to provide access for computing device 101A to the Internet 218 and to local content 220A-B at different times through network element 111 according to the prior art. Since the Internet 218 and the local content 220A-B are accessed through different contexts of the network element 111 in FIG. 2, the network element 111 in FIG. 2 requires that computing device 101A switch contexts to access either the Internet 218 or local content 220A-B. Specifically, FIG. 2 illustrates as an example the switch from the Internet to local content using the time phases shown by circled numbers 1-4. Circled numbers 1-2 correspond to the first authorization sequence of computing device 101A to network element 111, and circled numbers 3-4 correspond to the reauthorization sequence of the same computing device 101A to network element 111. Note that local content 220A-D often has different characteristics (e.g. timing demands, bandwidth demands, etc.) than typical Internet traffic. For example, local content can include streaming video, online computer gaming, voice over IP, etc. To provide relatively better quality of transmission, local content is often stored geographically close to a network element 111.
During the first authorization sequence in FIG. 2, the network element 111 receives a data signal from computing device 101A and the control module 106 negotiates with the remote database server 110 for authentication, authorization and accounting (AAA) information 208A. A single binding 215A in the virtual circuit unit 202A is established as a result of AAA negotiation for the computing device 101A (see circled 1). When traffic packets are received from computing device 101A, a source decision is made and packets are transmitted to context 107A according to the single binding 202A (see circled 2). Context 107A uses port 108A1 and/or 108A2 to establish communication between computing device 101A tolocal content 220A and/or local content 220B. At this time, the computing device 101A can access the local content 220A and local content 220B, but cannot access the Internet 218. When the subscriber on computing device 101A wants to access the Internet 218 through context 107D, the subscriber must be unbound from context 107A and reauthorize to be bound with the context 107D whether or not the subscriber is finished using local content 220A and/or local content 220B.
Specifically, during the reauthorization sequence in FIG. 2, the network element 111 receives a data signal from computing device 101A and the control module 106 negotiates with the remote database server 110 for authentication, authorization and accounting (AAA) information 208B. A single binding 215B in virtual circuit unit 202B is established as a result of AAA negotiation for the computing device 101A (see circled 3). When traffic packets are received from computing device 101A, they are transmitted to context 107D according to the single binding 215B (see circled 4). Context 107D uses port 108D to establish communication between computing device 101A to Internet 218. At this time, the computing device 101A can access the Internet 218, but cannot access local content 220A and/or 220B.
In contrast, FIG. 2 also illustrates four exemplary configurations (circled A-D) to provide access for computing devices 101A-I to the Internet 218 and/or to local content 220A-D through network element 111 according to the prior art.
First, circled A shows a configuration in which-context 107A uses ports 108A1 and 108A2 to communicate to local content 220A and/or local content 220B through network access translation (NAT) device 219A and network access translation (NAT) device 219B respectively. Disadvantageously, this configuration is relatively not scalable because it requires NAT devices for each local content connected to a port. Furthermore, disadvantageously, this configuration requires a high context configuration complexity (because it provides access to services on two ports). In addition, since a NAT device assigns port information, a NAT device is not source or destination port transparent (e.g., it cannot take advantage of port numbers used for on-line gaming). It should be noted that the word “port” when referring to a NAT device is different than the ports when discussing network element 111. The ports when discussing the network element 111 are physical ports 104-104I and 108A-108I. Physical ports are not to be confused with source and destination ports as indicated within packet headers or as referred to in conjunction with network access translation (NAT) devices.
Second, circled B shows a configuration in which context 107B uses ports 108B1 and 108B2 to communicate to the Internet 218 through NAT device 219C and to local content 220C. Disadvantageously, similar to configuration circled A, this configuration is relatively not scalable because it requires NAT devices for each local content connected to a port. Furthermore, disadvantageously, this configuration requires a high context configuration complexity (because it provides access to services on two ports).
Third, circled C shows a configuration in which context 107C uses ports 108C1 and 108C2 to communicate to the Internet 218 and to local content 220D. Circled C has the advantage of being scalable because it does not use a NAT device, however it is less secure because the local content 220D can be accessed over the Internet through the network element 111. In addition, configuration C still suffers from a high context configuration complexity (because it provides access to services on two ports).
Forth, circled D shows a configuration in which context 107D uses port 108D to communicate to the Internet 218 and context 107I uses port 108I to access local content 220D. The configuration shown in circled D would require a subscriber wanting to access both the Internet 218 and local content 220D through network element 111 to re-authenticate in order to switch between the Internet 218 and local content 220D. As a result, disadvantageously, simultaneous access of the Internet 218 and local content 220D is not possible with this configuration.